汎用的な継続的デリバリーツール PipeCD が出たぞ

GitOps は、Git をシステムにおける唯一の情報源として扱うコンセプトを持っています。つまり、Git ソースから全ての環境の変更や観察および検証ができる概念です。この記事では簡単なインテグレーションで Kubernetes 以外のリソースも GitOps 運用ができるようにサポートしてくれる PipeCD について紹介します。

#DevOps

#Kubernetes

#Terraform

#サーバーレス

キムインソ

2020.10.12

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Introduction

「Kubernetes 以外のリソースも GitOps 的にデプロイしてくれるやつが出たかよ？」

今月頭に汎用的に継続的デリバリーをサポートしてくれる OSS が発表されました。

https://twitter.com/pipecd_dev/status/1313299088905965568?s=20

名称は PipeCD。現在、Kubernetes はもちろん Terraform、CloudRun、Lambda までサポート対象になっていて、近いうちに AWS ECS のサポートもできそうな雰囲気です。デプロイの戦略は一般的なデプロイや Blue/Green デプロイ、Canary デプロイまで結構簡単に実現できますし、承認フローの設定とかも built-in されていました。

そして、デプロイ中に特定なメトリクスやログなどを指定して分析できる機能を通してもっと安全にデプロイの判断ができそうです。（まだ可視化画面はリリース前）

また、特定なクラスタ内部のデプロイを管理する piped っていうコンポーネントがあるんですが、こいつは Single Binary のため VM や Local でも起動することができるので、応用できる箇所が結構ありそうな感じでした。

Compare the FluxCD and ArgoCD and PipeCD

既存の継続的デリバリー OSS との差は何があるかなと思いつつ調べてみたら Q&A に書かれていたのでちょっと整理してみました。十分なメリットはあると思われるので、メインテナンスが続く限り適当な PoC 案件に導入したくなっちゃいました。

	FluxCD	ArgoCD	PipeCD
Kubernetes デプロイサポート	O	O	O
Kubernetes 以外（Terraform, CloudRun, Lambda)のデプロイサポート	X	X	O
複数の Git Repository	X	O	O
豊かな GUI	△	O	O
Multi-tenancy, Multi-cluster	O	△	O
秘密情報の内部管理 (built-in)	X	X	O
複数のクラスタへのデプロイ（シングルアプリケーション）	X	X	O
デプロイのパフォーマンス確認	X	X	O

Getting Started

「せっかくなので、軽く GitOps の雰囲気が感じられるチュートリアルをやってみましょう」

バージョン
- kubectl: 1.18.0
- eksctl: 0.29.2
- Kubernetes: 1.17.9
- Helm: 3.3.4

alias k="kubectl"
alias ek="eksctl"

Kubernetes クラスタを作成

$ ek create cluster \
  --name test-kim \
  --version 1.17 \
  --fargate

Pipecd のコンポーネント周りのリソースは直接管理したくないので、Fargate タイプでクラスタを生成します。約 10分以上かかるのでコーヒーとか飲みながら待ちましょう。

$ ek create fargateprofile \
    --cluster test-kim \
    --name pipecd \
    --namespace pipecd

クラスタの Fargate に Pod をデプロイするためには Fargate profile の設定が必要です。pipecdっていう namespace を切って Pipecd のコンポーネントをデプロイする予定なので、namespaceを指定しましょう。もっと細かい Fargate 対象を指定したいのであればlabelのオプションが使えるんですが、今回はサンプル試しなのでスキップで問題ないと思います。

$ ek get fargateprofile --cluster test-kim --name pipecd --output yaml
- name: pipecd
  podExecutionRoleARN: arn:aws:iam::xxxxxxxxxxxx:role/eksctl-test-kim-cluster-FargatePodExecutionRole-1E90LKRGXE1LD
  selectors:
  - namespace: pipecd
  subnets:
  - subnet-084ca2ea6ae3aedac
  - subnet-0f8723cbb25393b78
  - subnet-00d0f56db981cf8fd

上記の通り selectorsとしてnamespace: pipecdが指定されていることが分かります。

Pipecd のコンポーネントを Helm 経由でデプロイ

$ git clone https://github.com/pipe-cd/manifests.git
$ cd manifests
$ helm -n pipecd install pipecd ./manifests/pipecd \
    --create-namespace \
    --values ./quickstart/control-plane-values.yaml

NAME: pipecd
LAST DEPLOYED: Sun Oct 11 05:30:00 2020
NAMESPACE: pipecd
STATUS: deployed
REVISION: 1
TEST SUITE: None

とりあえず、Helm template 経由で Pipecd のコンポーネントをデプロイしてみましょう。コンポーネントのカスタム周りは control-plane-values.yaml を適当に変えることで可能な気がします。

$ k get pods -n pipecd
NAME                               READY   STATUS    RESTARTS   AGE
pipecd-api-98c4f56f-8kmlj          1/1     Running   1          5h57m
pipecd-cache-5458449b5-45c7q       1/1     Running   0          5h57m
pipecd-gateway-5bff6f657d-d97vz    1/1     Running   0          5h57m
pipecd-minio-6c8b74bbbb-sxbf8      1/1     Running   0          5h57m
pipecd-mongodb-7845d88b8f-grttj    1/1     Running   0          5h57m
pipecd-operator-6956bb9598-ct88w   1/1     Running   0          5h57m
pipecd-web-bf6546859-hptjl         1/1     Running   0          5h57m

7個の Pod がデプロイされていますね。この中で minio と mongodb はマネージドサービスに切り替えることができるらしいので、パフォーマンス周りの問題が起きたら AWS 基準に S3 とか DynamoDB に移行するのもありかなと思われます。

Pipecd の管理画面を確認

$ k -n pipecd port-forward svc/pipecd 8080:443 --namespace pipecd &
$ open http://localhost:8080

Ingress の port が 443 なので、適当な port でポートフォワーディングして、ブラウザを開けてみましょう。

なんかデザインがシンプルでアイコンも可愛いですね。Project Nameに quickstart を入れて CONTINUE ボタンを押します。

すると、ユーザー情報を入力する画面が出てくるんですが、今回は用意されているアカウントを使いましょう。ユーザー登録に GitHub アカウントも使えるので、プロジェクトごとの assign が結構楽な気がします。

Username: hello-pipecd
Password: hello-pipecd

やっとログインができました。今のところ画面の機能はざっくりこんな感じでした。

		Description
Application	-	デプロイの状態画面
Deployments	-	デプロイの歴史画面
Insights	-	デプロイのパフォーマンスが把握できる画面（未実装）
Settings	Piped	クラスタ内部のデプロイを管理
	Environment	プロジェクトの環境管理（開発・ステージング・本番環境とか）
	Project	ユーザーの管理。管理者アカウント、SSO（例、GitHub）と RBAC の設定ができる

GitHub レポジトリと連携

Settings → Environment → ADD

$ k exec -it pipecd-mongodb-7845d88b8f-grttj /bin/sh -n pipecd
# mongo
> use quickstart
> db.Environment.find()
{ "_id" : "625d770b-b39e-405c-b64a-34112e059922", "id" : "625d770b-b39e-405c-b64a-34112e059922", "name" : "dev", "desc" : "Development Environment", "projectid" : "quickstart", "createdat" : NumberLong(1602399845), "updatedat" : NumberLong(1602399845) }

Environment を適当に登録して、データを確認しましょう。

Settings → Piped → ADD

> db.Piped.find()
{ "_id" : "3b98db59-4fb3-486c-bb84-37e92fd8da34", "id" : "3b98db59-4fb3-486c-bb84-37e92fd8da34", "name" : "dev", "desc" : "Development Environment", "keyhash" : "$2a$10$S4vUe/U4HMiV2Gaz5l9GMu.zxpO4nDnl3vwv6dxqPKW4SFVeoqoLa", "projectid" : "quickstart", "envids" : [ "625d770b-b39e-405c-b64a-34112e059922" ], "version" : "", "startedat" : NumberLong(0), "cloudproviders" : null, "repositories" : null, "status" : 1, "disabled" : false, "createdat" : NumberLong(1602399888), "updatedat" : NumberLong(1602407796) }

そして、Piped から先ほど登録した Environment を指定して登録すると piped idとsecret key が発行されます。

Applications → ADD

args:
  insecure: true

config:
  data: |
    apiVersion: pipecd.dev/v1beta1
    kind: Piped
    spec:
      projectID: quickstart
      pipedID: 3b98db59-4fb3-486c-bb84-37e92fd8da34 # piped id
      pipedKeyFile: /etc/piped-secret/piped-key
      apiAddress: pipecd:443
      webAddress: http://pipecd:443
      repositories:
        - repoId: demo-pipecd
          remote: https://github.com/sano307/demo-pipecd.git
          branch: master
      syncInterval: 1m

secret:
  pipedKey:
    data: "emqnzq7eo76ivdh12hfhawipg4544n7comwnse2foo5g0yv5ju" # secret key

https://github.com/pipe-cd/manifests/blob/master/quickstart/piped-values.yaml を適当に修正した後に

$ helm -n pipecd install piped ./manifests/piped \
  --values ./quickstart/piped-values.yaml

クラスタ内部のデプロイを管理する piped コンポーネントを Helm 経由でデプロイします。

$ k get ev -n pipecd --watch
Assume Role MFA token code: 804931
LAST SEEN   TYPE     REASON              OBJECT                        MESSAGE
51s         Normal   SuccessfulCreate    replicaset/piped-744d548974   Created pod: piped-744d548974-sfl4x
51s         Normal   ScalingReplicaSet   deployment/piped              Scaled up replica set piped-744d548974 to 1
0s          Normal   Scheduled           pod/piped-744d548974-sfl4x    Successfully assigned pipecd/piped-744d548974-sfl4x to fargate-ip-192-168-153-9.ap-northeast-1.compute.internal
0s          Normal   Pulling             pod/piped-744d548974-sfl4x    Pulling image "gcr.io/pipecd/piped:v0.7.5-3-g48d3fc6"
0s          Normal   TaintManagerEviction   pod/piped-744d548974-sfl4x    Cancelling deletion of Pod pipecd/piped-744d548974-sfl4x
0s          Normal   Pulled                 pod/piped-744d548974-sfl4x    Successfully pulled image "gcr.io/pipecd/piped:v0.7.5-3-g48d3fc6"
0s          Normal   Created                pod/piped-744d548974-sfl4x    Created container piped
0s          Normal   Started                pod/piped-744d548974-sfl4x    Started container piped
...

$ k get pods -n pipecd | grep piped
piped-744d548974-sfl4x             1/1     Running   0          14m

piped のデプロイは約 1分ぐらいかかりました。

その後に Applications → ADD から GitHub とソースコードの経路を設定し登録したら Deploymentsの画面で Sync の状態が見れると思います。ちなみに、Sync の間隔はデフォルトが 1分であり、kind: Pipedの syncInterval で調整することができるっぽいです。

デプロイを試してみる

デプロイの歴史画面(Deployments)を見たら.pipe.yamlがないため、Sync に失敗しているっぽいので、コミットしてみましょう。

$ k get pods -n pipecd | grep kustomize
kustomize-7cf569d8df-x4m8t         1/1     Running   0          1m

正常に Sync されたっぽいですね！ちなみに、quickstart 向けの container image にバージョンを指定しないと ImagePullBackOffエラーになるので、適当にバージョン（例、v0.1.0)を指定する必要がありました。

$ k get pods -n pipecd | grep kustomize
kustomize-7cf569d8df-97jsv         1/1     Running   0          3m50s
kustomize-7cf569d8df-pfhc7         1/1     Running   0          6m59s
kustomize-7cf569d8df-x4m8t         1/1     Running   0          32m

Pod の replica を 1 → 3に変更するコミットをプッシュしましょう。問題なく Pod が 3個に増えたことが分かります。

Summary

特定なクラウドに依存したくないから流行っているマルチクラウド、ビジネスの戦略を早く実現したいから流行っているサーバレスやコンテナ技術。これらのデプロイを汎用的にサポートしてくれるツールはこれまで存在していなかったため、これからの PipeCDがもっと期待されます。次回は直接運用する時の様々なユースケースを試してみたいと思います。

この記事が誰かのお役に立てれば幸いです。

以上、CX事業本部 MADチーム、キム (@sano3071) でした。